ext2/ext3ファイルシステムはデータブロック、iノードブロック、スーパーブロックというブロックで管理され、ブロックグループという単位でまとめられています。

● データブロック

データが格納されるブロックで、1ブロックのサイズは1024バイト、2048バイト、4096バイトの中からファイルシステム作成時に作成する。ファイルシステム上では、８つのセクタ＝4096バイトを、1データブロックとして管理するのが主流
※ 1バイトのデータを格納するにも1データブロックが必要になるので、小さなサイズのファイルを作成する場合には注意が必要

● iノードブロック

データブロックの格納内容がiノードに記録される
i-nodeには、管理するファイルのデータが、どのデータブロックに保存されているかの情報が保存されている。
ほかにも、ファイルタイプ、アクセス権、所有者、所有グループ、ファイルサイズ、作成日時などのメタデータが格納されている
iノードのサイズは128バイトで1ブロックが1024バイトの場合は8つのiノードが格納されている
iノードは後から追加することはできないため、iノードを使い切ってしまうと新規にファイルが作成できない
ReiserfsやXFSではiノードを動的に追加できる動的iノードという仕組みがあるため、iノードが枯渇することはない
i-nodeがいくつ必要かは事前には分からないので、4096byte×4＝16,384バイトに1つの割合で、i-nodeを作る。
・ファイル種別
・ファイルサイズ
・アクセス権
・所有者
・リンク
・ディスク上の保存場所（ブロック番号）
※ファイル名の情報は、i-node上ではなく、ディレクトリのデータブロック上に収められており、そこで、i-node番号と、ファイル名が紐付けられている。

● スーパーブロック

ファイルシステムの全般的な情報（データブロックサイズ、マウント回数、iノードやデータブロック数など）が格納されている 非常に重要なためブロックグループごとにバックアップが作成される（バックアップスーパーブロック）
スーパーブロックはディスクパーティションごとに1つだけ用意されているため、複数の ディスクパーティションをmke2fsコマンドで初期化した場合、それぞれのパーティション （区画）にスーパーブロックが作成される。
・パーティション内のデータブロック数
・ブロックサイズ
・空きブロック数
・iノード数
・空きiノード数

【 ext2 】
パーティションの上限は当初2GiBでしたが、2.4系カーネルでは4TiBまで拡張されています。255バイトまでのファイル名や、可変長のディレクトリエントリに対応しています。また、一部をスーパーユーザー (root) のために予約しており、通常の領域を使い切ってもメンテナンスを行うことができます。
ext2 は、ジャーナリングを備えていないため、いったんクラッシュするとファイルシステムの復旧に時間がかかります。そのため、ext3 や ReiserFS などのジャーナリングファイルシステムの使用が進められています。
ext2 の空間はフラグメントを減らし、ディスクシークを最小化するためにブロックで分けられており、ブロックグループを作りグループ化します。
最大ファイル サイズ 2TiB
最大ファイル数 10^18
最大ファイル名長 255バイト
最大ボリューム サイズ 16TiB

【 ext3 】
ext3 は、ext2との互換性を維持したまま、ジャーナリング機能を付加した互換ファイルシステムです。
ext2に比べext3には以下の機能が加わっています。

• ジャーナリング
• 複数のブロックに跨るディレクトリに対してのツリーベースのディレクトリインデックス
• オンラインファイルシステムリサイズ(拡張のみ)
• dir_indexオプションをつけると、ディレクトリ内の検索に、hashed b-tree を使うことができ、ディレクトリ内に多数のファイルがある場合、劇的に高速化する。

　ext3の主なメリットは次のとおりです。

• クラッシュ時の起動時間の短縮
  ext2とext3がベースとしているブロックアルゴリズムは安定している半面、起動が遅いという問題があった。ext3は、ジャーナリング機能を実装することで起動時間の短縮を実現した。
• 互換性
  ext3とext2は基本構造が同一なので、ext2からext3への変更などを簡単に行うことができる。
• 性能
  ブロックのアロケーションや基本的なアルゴリズムはext2と同じだが、コードはext2をそのまま利用するのではなく、スクラッチから書き直された。そのため、ext2に比べてエラー処理やロック、ファンクションの実行手順、アトミック操作など、細かい点で改善が見られる。I/Oについても、ディスクへのフラッシュと非同期に行うことで効率の良い書き込みを実現している。

最大ファイル サイズ 16GiBから2TiB
最大ファイル数 指定による
最大ファイル名長 255バイト
最大ボリューム サイズ 2TiBから32TiB

【 ext4 】
ext4 ファイルシステムは、ext3 ファイルシステムの次世代の水準として、ディスク容量の増加に伴う巨大なファイルシステム (64bit) を扱うのに必要な拡張性と信頼性を向上し、最新の機能要求に応えたものです。
1EiBまでのストレージ容量と最大16TiBまでのファイルサイズをサポートし、ファイルの断片化を防ぐ extent file writing と呼ばれるシステムが導入されいます。
最大ファイル サイズ 16TiB
最大ボリューム サイズ 1EiB

【 ジャーナリング 】
ジャーナリングは、ジャーナル（またはログ）と呼ばれるデータを定期的に記録する技術で、もともとはデータベースで用いられていました。ジャーナリングファイルシステムはこの技術を応用したもので、ファイルシステムの更新内容をジャーナルログに記録します。システム障害などが生じた際に、ログに記録された内容を確認するだけでよいので起動が速くなり、かつその情報を基にした復旧が可能となります。
データベースで用いられるジャーナリングの目的がデータの保全であるのに対して、ジャーナリングファイルシステムの目的はデータそのものではなく、ファイルシステム全体を保護することにあります。ファイルシステムの保護のためには、ファイルシステムを構成・管理する情報である「メタ・データ」の整合性が必要です。つまり、ジャーナリングファイルシステムにとっては、メタ・データを適切に保持し、更新の処理を行うことが主な目的となります。

ジャーナリングに対応したファイルシステムでは、ディスクにデータを書き込む際に、直接データを書き込むのではなくて、「ジャーナリング」（または「ログ」）と呼ばれる場所に、その操作を一旦書き込んでおきます。そして、その後、本当にディスクへのデータの書き込みを開始し、データの書き込みが完了した時点で、ジャーナリングからその操作を消します。つまりジャーナリングの領域に、これから操作する手順を書いてから、実際の操作をし、操作完了後に手順を削除するようにします。
このようにしておけば、もし、ファイルへの書き込み時にシステムが不正に終了しても、再起動後にジャーナリング内に何も残っていなければ、実際にディスクへの書き込みが完了したことを意味します。
もしジャーナリング内に何か残っていれば、ディスクへの書き込みに失敗した可能性があるということがわかります。このときジャーナリング内に記載された手順内容を見れば、どのような操作をしたかがわかるので、壊れた可能性がある箇所がわかります。よってその箇所だけを調査すればよい。すなわち強制的に全メタデータを調査するfsckコマンドによるものと違い、壊れた可能性がある箇所だけを調べることで、不正なシャットダウン後のディスクチェックの時間を短縮することができます。

【 メタデータ 】
データについてのデータ。データそのものではなく、そのデータに関連する情報のこと。データの作成日時や作成者、データ形式、タイトル、注釈などのことです。データを効率的に管理したり検索したりするために重要な情報です。

XFSはSilicon Graphics（SGI）が開発したジャーナリングファイルシステムです。XFSの開発が開始された当時、SGIはすでにEFS（Extent File System）というファイルシステムを持っていました。SGIがXFSで目指したものは、次世代の拡張性を考慮した64bitファイルシステムを新規開発することでした。
XFS開発の背景には、今後Tbytesオーダーのディスクが主流となったときに、32bitファイルシステムでは限界があるという認識がありました。32bitファイルシステムでは40億個のブロックしか作れないため、ブロックサイズを8kbytesとすると32Tbytesまでしか扱えません。
開発チームは当初からこの問題を考慮し、64bitファイルシステムやアロケーショングループという手法を採用することで巨大なファイルシステムを扱うことを可能にしました。また、サイズの大きなファイルは書き込み／読み込み領域を確保したり、ディスク上の空き領域を検索するのに時間がかかるといった問題があります。そのためXFSでは、遅延アロケーションやB+-Treeによってこれに対処しています。
XFSは64ビットのジャーナリングファイルシステムであり、ファイルシステムの整合性が保証されています。ファイルシステムサイズは最大で8EiBですが、通常ホストオペレーティングシステムの仕様によりそれよりも少ない容量に制限されます。たとえば32ビット Linuxにおいては、最大16TiBです。 削除されたファイルの復元はほぼ不可能です（これは長所でもあります）。
最大ファイル サイズ 8EiB
最大ファイル名長 255バイト
最大ボリューム サイズ 8EiB

「xfs_info」で、指定した場所にマウントされているファイルシステムの詳細情報を表示します。
以下は、ルートにマウントされているファイルシステムの詳細情報を表示する

xfs_info　[オプション]　場所

meta-data=/dev/mapper/cl-root    isize=512    agcount=4, agsize=1113856 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=4455424, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

[meta-data]セクション : i-node等のメタ情報関連
[data]セクション : ファイルの中身等データ領域関連
[naming]セクション : ディレクトリ関連
[log]セクション : ジャーナルログ関連
[realtime]セクション : リアルタイム関連

XFSファイルシステムをチェックする。

xfs_check　[オプション]　デバイス

XFSファイルシステムを検査、修復するには xfs_repair コマンドを使います。

xfs_repair　[オプション]　デバイス名

-L	ログを強制的に消去（ゼロで初期化）する。ログが破損していて修復できない場合に使用
-P	先読み（プリフェッチ）を行わない。xfs_repairの処理が途中で停止してしまう場合に使用
-d	リードオンリーモードでマウントされているデバイスを修復する（「d」angerousな修復）
-m サイズ	xfs_repairコマンドが使用するメモリの最大値をMB単位で指定する
-f	デバイスの代わりにファイルシステムのイメージファイルを指定する
-l デバイス	ログを保存した外部のデバイスを指定する
-d	リードオンリーモードでマウントされているデバイスを修復する（「d」angerousな修復）
-r デバイス	ファイルシステムのリアルタイムセクションが存在する場所を指定する
-c パラメーター	ファイルシステムのパラメーターを変更する。「オプション=値」の形式でパラメーターを指定
-o パラメーター	ファイルシステムのパラメーターをオーバーライドする
-t 秒数	動作ログを出力する間隔を指定する（デフォルトは15秒）
-n	検査だけで修復は行わない
-v	実行時のメッセージを詳しく表示する

/dev/sdb2の検査だけを行う

meta-data=/dev/mapper/cl-root    isize=512    agcount=4, agsize=1113856 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=4455424, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

ReiserFS は従来のデータベースで実装されてきたB-Treeアルゴリズムをファイルシステムに実装する試みとしていて、開発当初よりB-Treeアルゴリズムを効率よく実装することを目指していました。
Reiser氏を中心とする開発メンバーは、このB-Treeアルゴリズムをさらにファイルシステムに適したB*-Treeとしました。B*-Treeではデータオブジェクトをツリー構造の中に収め、ノードの検索に当たる部分をキャッシュに置くことで高速な検索を実現しています。
大きなファイルの読み書きはハードなどの制約があるため差が出にくいですが、多数のファイルがあるディレクトリで目的のファイルを探す場合などは、このアルゴリズムのメリットが有効です。

ext2/ext3ファイルシステムと互換性は無い。
最大16TiBまでのボリュームサイズをサポートする。
最大8TiBのファイルをサポートする。
ext2/ext3よりもパフォーマンスに優れるとされており、特にサイズの小さいファイルを多数処理する際に優れている。
最大ファイル サイズ 8 テビバイト
最大ファイル数 2³² (~42億)
最大ファイル名長 4032バイト/255バイト(VFSによる制限)
最大ボリューム サイズ 16 テビバイト

ReiserFSファイルシステムのチェックを行う（fsck.reiserfsコマンドも同様）

reiserfsck　[オプション]　デバイス

--check	整合性をチェックする（デフォルト）
--rebuild-sb	スーパーブロックを修復する
-y	問い合わせに対し自動的に「yes」と回答

ファイルシステムのパラメータ変更を行う

reiserfstune　[オプション]　デバイス

-s ブロック数	新しいジャーナルサイズを指定する
-l ラベル	ラベルを設定する

ファイルシステムの対話的な修復を行う

debugreiserfs　[オプション]　デバイス

-j デバイス名	ジャーナルの内容を表示する

• システムユーティリティを使用して、Linuxファイルシステムを適切に保守できる。これには、標準的なファイルシステムの操作およびSMARTデバイスの監視が含まれる。

• ファイルシステムを操作するツール
  mkfs (mkfs.*), fsck (fsck.*)
• ext4を操作するツール
  tune2fs, dumpe2fs, dump, restore
• XFS を操作するツール
  xfs_info, xfs_check, xfs_repair, xfsdump, xfsrestore
• subvolumes と snapshots を含む、 基本的な Btrfs を操作するツール
• ext4 ファイルシステムをBtrfsに変換したり操作する。
  btrfs, btrfs-convert
• HDD, SSD の健康状態を監視できる。
  smartd, smartctl